Various mechanisms exist for implementing virtual machines in a single platform. A class of software known as virtual machine monitors (VMMs) enables a single platform/processor to simultaneously support multiple guest operating systems. Intel® Corporation's Virtualization Technology (VT) enables the efficient execution of VMMs on Intel® Architecture (IA) processors (and eventually platforms).
In VT environments, guest operating systems (OSs) are each provided a “virtual machine” (VM) view of the processor and platform and the guest OS is typically unaware that it is not controlling all of the processor or platform resources. The motivations for utilizing VMMs have included consolidation of physical hardware (e.g., one hardware platform consolidates the software previously executed on multiple physical platforms) and resource partitioning for any combination of manageability, security, and quality reasons (e.g., a platform hosting multiple guests can use a VMM to provide isolation and better service to those hosted applications which pay higher fees).
Intel® Corporation's Virtualization Technology (VT) environments enable creation of a new “higher” (more-privileged) privilege level, called “root mode”, which enables the VMM software to control processor and platform resources and present a view of the hardware resources to existing guest operating systems that the guest OS is in control.
Currently, VT is used to create VMM software that schedules and isolates the execution of multiple guest operating systems. The computational model is that both performance-critical and non-performance critical code for a domain or application is run in the same guest operating system (VT non-root mode) and the software in VT root mode is only there to ensure isolation and fairness between the guest operating systems.
As has been noticed by industry practitioners, there have been performance issues with using general-purpose platforms to be used as embedded, or domain-specific, devices such as networking devices. Types of devices may include intrusion detection or XML acceleration, but may apply to other domains, as well. The problems relate to applications that need access to services from a general-purpose operating system (GPOS), for instance Linux®, BSD®, or BSD-variants like FreeBSD®, NetBSD®, or OpenBSD, Windows®. Performance of such domain-specific applications running under the general-purpose OSs tends to be poor. For network devices in particular, problems included too many interrupts or a large number of buffer copies. To counteract this, vendors have made significant modifications to the general-purpose OS to accommodate the networking applications. In other words, vendors have gotten around the problem by implementing customized domain-specific run-time environments (DSRTE) tightly integrated with the GPOS. These platforms are very difficult to maintain. When an update to the general-purpose OS was made, it often had a “domino” effect requiring changes to the DSRTE. Some changes to the GPOS may be modifications to kernel modules, similar to a dynamic link library (dll) for the kernel module, but also changes to the scheduler or network stack. Non-dll modifications, or direct changes to the GPOS, are extremely difficult to maintain when the GPOS is updated or modified.